Digital certificates and the public key infrastructure (PKI) are well-known mechanisms for electronically authenticating individuals. In the PKI, each entity has a unique, asymmetric key pair, comprising a public key and a private key. A certificate authority (CA) issues a digital certificate, listing the entity's identity credentials (e.g., name and organization) and the entity's public key, binding the entity's identity to his public key. The entity may then encrypt all (or a hash) of its outgoing message with its private key, and may distribute its digital certificate along with the encrypted message. The message recipient can decrypt the encrypted message using the sender's public key, allowing the recipient to confirm that (i) the sender has access to the corresponding private key, and therefore (ii) the sender is the individual identified in the digital certificate.
However, it is also known that digital certificates can be forged. Thus, usually, when a CA issues a new digital certificate, the CA will digitally sign the certificate using one of its own private keys. The CA will then publicize its own digital certificate, identifying itself and the corresponding public key. This will allow a message recipient to confirm that the sender's digital certificate was issued by the CA. The digital certificate has become more difficult to forge (because it required use of the CA's private key) and becomes more trustworthy.
It may be, however, that the purported CA is not trustworthy. (For example, a malicious user may have created his or her own “CA” for the purpose of signing digital certificates.) As a result, it may be desirable for the CA's digital certificate to be signed by yet another CA. This chain may continue all the way back to a “root certificate” at the top of the hierarchy, which, preferably, has been issued by a well-known and trusted CA. Common root certificate-holding CAs are VERISIGN, ENTRUST, COMODO and GLOBALSIGN.
In the field of information security, systems that rely on root private keys and root certificates are very common. Ultimately, the trustworthiness of the chain is dependent on the trustworthiness of this root certificate. Two well-known issues related to such systems are (1) the secure storage of root private keys, and (2) the population of root certificates within the systems that require them for authentication.
Usually, the root certificate is made trustworthy by some mechanism other than a digital certificate, such as by secure physical distribution. For example, some of the most well-known root certificates are embedded in hardware or software at the time the hardware is manufactured or software is installed (for example, root web certificates are normally embedded into Internet browsers).
This method for distributing root certificates relies on security which is external to the system and the previously stored root certificates themselves, which has its drawbacks. In particular, if such a root certificate (or the private key corresponding to the root certificate) is compromised, there is no secure way of updating it within the device; rather, it must be performed by some mechanism that is external to the system. For example, a system administrator might be required to download a new browser from a supposedly secure source. Moreover, once compromised, this root certificate cannot be used to verify the integrity and authenticity of a message containing a new root certificate to be used. As a result, the device essentially becomes unable to verify the identity of any senders from which it receives a message. Depending on the context, this may render the device itself useless.
What is needed are systems, methods and devices for securely making new root certificates available to electronic devices after a root certificate currently in effect becomes compromised.